The AmigaOS conference, held in IRC channel #Amiga-OS on 4/4/95

The AmigaOS conference, held on what is becoming a very popular channel on IRC, is one of the examples of developers taking things into their own hands; if nobody does the work, everything stagnates; these people, whether participating in discussion or writing code, all deserve more credit than they get. Becuase no matter how difficult writing code is, writing good code is one leap harder; and no matter how good that code is, without an interface and a plan of implementation, it's meaningless. Here's to the planners, the thinkers, and the shakers out there.

Tau:

suggested vote topics: binary compat, memprot, resource tracking, multiuser filesystem, clone 3.1/go for new

stefanb:

Tau: Binary compatibility = NO, all others semm OK.

Tau:

sb, why not? can load old binaries, doesn't mean every new feature oughta work with them

mlelstv:

tau, why new binaries ?

Tau:

mlel, stefan just said no to binary compat.

stefanb:

Tau: We should fix all brain-dead system calls. OK, if we make "compat" libraries for old binaries. The new libraries should have newly designed System calls.

mlelstv:

tau, can't understand that..

BM:

stephanb, Agreed. :)

mlelstv:

tau, I fear we get a committee decision..

Tau:

stefan, I'm against that.. we should keep it as compatible as possible, but not be afraid of breaking some things if an essential feature demands it

stefanb:

ml: Maybe there is no "correct" answer. Then we have to make a decision what _most_ programmers want.

Lynet:

Tau: How do we add MP and RT without breaking 99% of the old apps?

stefanb:

Tau: Most esential new features require breaking the old stuff.

mlelstv:

stef, as I said.. then either some people will leave the project or we have two teams working on different designs.

griesbrei:

Lynet: RT with an extra library

Lynet:

griesbrei: Use cooperative RT?

mlelstv:

stef, as for me. I am not interested in a 'I can do it better'-design.

stefanb:

ml: Then this only means that Amiga people are the same as UNIX people. They can't work together for a common goal.

griesbrei:

lynet: cooperative??

Tau:

lynet, I posted a long article about how I'd do it on the mailing list some time back. Seems to me device drivers would break, most other things could be left functional

Tau:

stefan, UNIX people can work together?!

stefanb:

Tau: They can't. example: NetBSF <-> FreeBSD.

Lynet:

griesbrei: I.e. that each application has to thell the OS it wants RT.

Pepo:

resource tracking comes free with an OO system. Old programs would simply not be be tracked.

griesbrei:

maybe the first thing we should add is a global Amiga time ;)

WilloW:

No I'm not kidding.. he didn't recieve the announce message you posted.. Really wierd.. he's quite busy also..

Arcade:

Ah ... that's bad.

stefanb:

Pepo: We could do "compatibility" libraries for old binaries.

Arcade:

Indeed ... that's what I propose.

stefanb:

Pepo: They would be mapped to the new calls.

Tau:

gries, pisses me off I have to actually adjust the clock for daylight savings.. Locale should remember that for me, just like it does for my timezone ;)

griesbrei:

lynet: that`s it. add a hook for each resource you want to be freed

BM:

Stub like stuff yo umean?

Pepo:

stefanb: oh, you can't build an whitebox api over an blackbox api. the new stuff has to be based on the old stuff, not the other way around.

Arcade:

tau: that's a thing to add ... :)

griesbrei:

tau: maybe some sort of rsadio controlled clock..mmmh

mlelstv:

pepo, nah. everything gets translated for and back :)

BM:

Nah, Synclock is fine for that. :)

PieMan:

hates daylight savings

Arcade:

Or syncro.

WilloW:

yes!!!!

Pepo:

mlelstv: it's impossible

Tau:

I actually had to adjust my time zone to russian time (-3) to keep my clock in time.. since it's adjusted automatically from my host

mlelstv:

pepo, you can simulate everything.. look at multifinder :)

griesbrei:

mlel: why not simulate a Cray ;)

stefanb:

Pepo: Then compatibility is completely impossible, even if we leave the old calls in and add new ones.

Tau:

mlel, umm.. that makes my eyes sore ;)

Murty:

Okay, I'm here. Sorry I'm so late, guys : to be honest, I just forgot the entire conference ! :-(

Arcade:

Okay guys, welcome to this channel. Sorry if it means an inconvenience to some of you.

stefanb:

gries: Who wants such a piece of crappy hardware?

Pepo:

stefanb: huh? how does leaving old stuff in break compatibility?

mlelstv:

tau, well, that's why I don't like the 'complete new OS that simulates the old'-approach.

griesbrei:

stefan: yep, i like my pocket calculator most..

stefanb:

Pepo: You still have your white-box API in. So the new black-box API can't work securely.

mlelstv:

tau, in fact, if we want to do that we should concentrate on an existing kernel such as Mach..

Tau:

mlel, me neither

griesbrei:

SO, CAN WE START?

Pepo:

strefanb: we are not UNIX. We don't need a secure OS.

Arcade:

Why would we need to use a kernel such as Mach?

stefanb:

ml: Not everything has to go, only the wrong decisions have to be removed.

mlelstv:

tau, problem with that is you need big machines to get something reasonably fast.

stefanb:

Pepo: secure = stable.

Tau:

exactly.. if we were to build emulation libraries, we might as well write them for some existing OS

mlelstv:

stef, wrong decisions such as FindTask() and Disable() ?

BM:

Security is essential for multi user machines, not single user ones.

stefanb:

ml: What's wrong with FindTask()?

mlelstv:

stefanb, direct access to the TCB

BM:

Forbid()?

Arcade:

How about networking? multiuser security is valuable then.

Pepo:

stefanb: _old_ programs wouldn't benefit from the OO "overlay", but new ones will

griesbrei:

stefan: it cannot return easter eggs..

stefanb:

Pepo: But the OO overlay can't be stable if you have an old app running, which uses white-box access.

Murty:

Arcade : when you do networking, multiuser security is a *must*.

BM:

Hmm, not at the process level though, checking ownership of everything wuld be a drag.

Tau:

has work on dos started, btw?

Murty:

BM : No, I'm talking file system level here.

Pepo:

stefanb: how would it work with emulation libraries then?

mlelstv:

stef, without memory protection nothing is stable..

griesbrei:

tau: in fact, we didn`t start on anything yet :(

Tau:

murty, OS 3.0 already supports multiuser at filesystem level.

BM:

Oh, for sure, some superficial security would be neat to have.

stefanb:

ml: VMem is easy, just allow Pools with VMem...

Murty:

Tau : yes, but don't ask how. There are security gaps in 3.0 and even in MultiUser.

mlelstv:

stefanb, I do know that.. I was talking about protecting memory.

Arcade:

tau: the problem is that program's dont. having basic support in the OS makes programs support it too.

stefanb:

ml: I was just pointing out to Pepo that if his argument is right, then we CAN'T produce a compatible OS.

Pepo:

stefanb: so you want to _interprete_ the programs to keep track of what fields in a structure are written to?

mlelstv:

stefanb, why not ?

Pepo:

stefanb: old programs, I mean?

Tau:

arcade, what basic support?

stefanb:

ml: Compatibility Libraries or new system calls in the old libraries are virtually the same.

mlelstv:

stef, my idea is to have pools mapped to memory regions (lists of MMU pages). A task can have private pools. The loader could allocate private pools for code segments, etc..

Arcade:

pepo: we would wan't to have a basic multiuser security, not very severe. Something like muFS, but better support from within the OS.

BM:

Arcade, Agreed.

Murty:

stefanb: When was the last time you received anything ?

Tau:

arcade, give an example, how is filesystem level support on OS 3.0/MuFS not enough?

BM:

Can you store owneship info in 3.0?

Lynet:

Arcade: AmigaOS is a single user design. Why clutter it with multiuser support?

Tau:

you can't Open() a file you have no access privilege to. That's what the OS is supposed to make sure

Pepo:

stefanb: just how would you make old intuition gadgets work, when the "native" OS only supported gadget objects (boopsi or gadtools)?

Murty:

stefanb: Well, at least it seems there isn't a problem with your address and the list then.

Arcade:

tau: It doesn't provide for other things like disabling the bootmenu, formatting harddrives, etc.

Beefeater:

Lynet: When you hook it up in a network

mlelstv:

bm, yes. you have 2 words for user id and group id. isn't used by the filesystem for access control though.

Tau:

bm, FastFileSystem doesn't store ownership, but muFS/Envoy do. dos V39 has the calls necessary

stefanb:

all: Shouldn't we start with a first topic and then discuss the next?

mlelstv:

tau, fastfilesystem stores ownership!

Lynet:

Beefeater: When you hook your Amiga to a network, let the network service daemons take care of multiuser security.

Murty:

stefanb: Yes, I agree. Let's take it one thing at a time.

Arcade:

And access control is what we need (or want). I can be disabled though.

Tau:

mlel, well, it doesn't use it then.

mlelstv:

tau, it's just ignored. Envoy evaluates the uid/gid

Arcade:

Okay, let's talk about binary compatibility for now ...

stefanb:

Murty: Go ahead, set the first discussion point. I think the main talk should be about Exec first...

Murty:

Binary compatibility it be. There are two things to be considered here...

mlelstv:

arcade, we do need binary compatibility. the OS should run on existing machines with existing programs.

Murty:

...one : we can easily use older programs...

Arcade:

Would it be a bad idea to just write a 'new' OS, and make it possible for old apps to use our 'emulation' libraries like intuition.library etc.?

Murty:

...two : we are restricted in adding new features and/or changing fundamental things when we do go for binary compatibility.

Tau:

arcade, yes. why write the OS in the first place, then? Why not just make an Amiga emulator for OS/2, Hurd, Linux or something?

BM:

If it can boot on an amiga you can choose to boot it or not, no?

Murty:

Well, we can't make the OS OO-oriented from the bottom up, when we wish to go for binary comp., because...

Arcade:

Because we want to take ourselves and others to the future?

rozga:

KMEL: Please drop me a mail after this disc. (rossi@tindrum.tng.oche.de)

Murty:

...then library calls would fail. Unless we make a lot of emulation libraries, which would mean emulating the OS and not so much rewriting it.

Murty:

(as you can see, I'm writing in pieces :)

griesbrei:

I guess we all want to use existing programs, don`t we?

Murty:

Emulating the OS is bound to be slow for older programs, which is all we'll have at first.

mlelstv:

murty, why would library calls fail ? I do not want to junk all software that exists.

Murty:

griesbrei : I know I do. If I wanted to switch to new software, I would buy another computer.

Pepo:

griesbrei: as long as they are coded to the rulez: yes.

Arcade:

True. One would be able to boot the 'old' OS anyway. And these programs will certainly not work on other hardware anyway.

Murty:

mlelstv: if library calls are redesigned, they will respond differently and programs who rely on the old method will break.

Arcade:

Every program that is system compliant, would run on these libraries.

PieMan:

I'm afraid the hard truth is everyone is going to want to use old software that would be incompatible with out os.. as a result everyone says "hey WB 3.1 ain't so bad" and our project is a flop

Pepo:

Arcade: SWITCH? I.e. not beeing able to run them TOGETHER? :-(

Kudo:

I think binary compatiblity will make it harder to make a good OS with new features

mlelstv:

murty, no. the library calls define the interface to programs. these library calls must exist. otherwise it is not AmigaOS anymore but something completely new.

Arcade:

Pepo: Not concurrently, no. Impossible.

Tau:

arcade, I won't be rebooting my machine every time I want to use another program

griesbrei:

PieMan: Nobody will use a new OS without any software..

BM:

mlel, To a point. If the calls are only slightly different then porting is a snap.

Murty:

mlelstv: Exactly. If you change the design so fundamentally that the library calls change...

Arcade:

pepo: But if we do our job properly, one would be able to run old programs under the new OS. System-compliant programs, that is.

Murty:

...i.e. no binary compatibility...

mlelstv:

murty, then this is no longer AmigaOS. I don't think that anybody wants that.

griesbrei:

murty: so we need new libraries!

Lynet:

mlelstv: But adding memory protection and resource tracking without changing some of the API would be very difficult.

Murty:

...then you will have a different API and you will indeed have to run 3.1 to run old software.

PieMan:

griesbreg: i agree.. and they have a choice so they just won't choose it...

mlelstv:

bm, the calls have to be the same, to the word of the documentation

Kudo:

think it would be better to go for source compability

Arcade:

Yes. We would use new libraries instead of the old ones, the old ones would be used for compatability.

Pepo:

Arcade: I remember reading something different, but this is the way to go, old programs _should_ work

Murty:

mlelstv: I agree with you ! I do ! I want to keep using my old software, and making the library calls compatible is the only way to do that.

Tau:

If the calls are only slightly different, WHY change them at all?

mlelstv:

lynet, indeed. with (full) memory protection, you have to write a complete new and incompatible OS

BM:

mlel, existing documentation of 3.x? Or New docs?

Arcade:

Because the underlying system would be very different.

Kudo:

murty: if we only want to use old software, There's no use writing a new OS.

mlelstv:

bm, existing documentation of 3.x.

Murty:

However, if we would go 'for the future' with a completely new OS with MP and all, it would be very hard to keep the old library calls.

mlelstv:

bm, I insist in compatibility to the word. we do not have to copy the bugs :)

Lynet:

mlelstv: I understand that. The AmigaOS is so dependant on publically available structures that adding full MP would be impossible.

Murty:

Kudo: Yes there is. Say your Amiga dies or becomes too slow. Then you can get a new machine and run your old software on it.

mlelstv:

murty, it would very hard to keep existing software..

Kudo:

murty: but not the same binarys...

BM:

mlel, I'd like a cleanup and simplify done to 3.x. :)

Pepo:

OK, let me make this point clear: If the ultimate goal is to write a new OS, that doesn't look and feel like AmigaOS (from the _programmers_ standpoint of view), I'll leave the project.

Arcade:

Murty: Only if these programs would be recompiled anyway.

Kudo:

murty: unless it's a 68k machine

Murty:

mlelstv: No, I don't think so. You'd have to recompile the source for a new processor, but that's about it.

griesbrei:

We needn`t keep the old software until the end of the world!

mlelstv:

lynet, yes.. and no. the number of public structures isn't that large. it mainly affects hacks and small utils

stefanb:

Pepo: That's NOT the goal.

BM:

Look and feel no problem, but strict compliance would be redundant.

mlelstv:

stefanb, sure about that ? I am not.

stefanb:

Pepo: But IMHO we have to make the decision if we want to fix the design failures in some of the current calls.

Pepo:

stefanb: actually, memory pretection _would_ make the OS look completely different.

Arcade:

pepo: We would want a very similar system, as similar as possible but with new features and portability.

_ZinO_:

'll be back in an half an hour..

Murty:

Pepo: MP makes it almost impossible to stay compatible.

Kudo:

agrees with Arcade

stefanb:

Pepo: And the question is, is this possible with adding just some replacements to the current libraries which are ONLY used by new programs.

desrat:

if we do have MP..please make it optional

griesbrei:

Can`t we put old stucts in public mem?

mlelstv:

murty, mp as a security feature: yes, as a debugging aid and crash protection: no.

Arcade:

We have to. Not everybody has an MMU (like me). :(

Tau:

MP should be a user option, just like it is on OS/2. For different reasons, of course...

Kudo:

Think we should stay as (source) compatible as possible, but not if it will sacrifice efficensy or something else

BM:

Optional MP would be required if we want anyone to actually try it out. :)

mlelstv:

griesbrei, yes. but if these are not protected you can crash the system.

Murty:

Tau: if we put MP in, we will have to make a very big effort to squeeze it in and be able to use old software at all. Making it optional too will only make things even more complicated.

Pepo:

stefanb: "this" ?

BM:

Really secure memory protection would be almost impossible I think.

Arcade:

You can't protect public accessible structures, it will break everything. At least under the current OS.

stefanb:

Pepo: Replacint brain-dead functions.

Tau:

bm, partial's better than nothing

Pepo:

stefanb: replace as in remove?

Murty:

Arcade: Yes, you will break everything. I say forget the MP and go for as much compatibility as possible.

stefanb:

Murty: MP for Pools is the best option for this.

Tau:

arcade you don't protect on a structure by structure level anyway

stefanb:

Murty: BUT the OS has to know about it and use MP pools as far as possible.

Arcade:

No, that would be impossible with the MMU pages.

Murty:

stefanb: How hard are pools to implement in the current API ? I wouldn't know, really.

Arcade:

Pools are already there, I believe.

Murty:

I mean MP pools, of course.

mlelstv:

murty, I think it is quite easy to get protected and virtual pools.

stefanb:

Pepo: THAT is the question: remove -> compatibility libaries, replace -> add them to the existing libraries.

Pepo:

every new app could call the exec function ProtectMe() in startup and all allocmem's (non-public) would be protected, and even automatically put in a pool which is freed at RemTask()

Murty:

mlelstv: This would be a good way to implement MP, make it optional and (thus) be able to remain compatible by switching it off.

Murty:

But can it be done with MP pools ?

BM:

I think flags during memory calls would be ideal.

stefanb:

Murty: Just add an option for MP for the already existing memory pools.

mlelstv:

pepo, could even be a feature of the loader.

Pepo:

mlelstv: agreed, magic hunktypes :)

zchu1121:

pepo: You could as well use the uid.

Murty:

stefanb: This would mean that only newer software can use MP, right ?

mlelstv:

pepo, you even have a supported extension of hunk memory type that isn't utilized yet.

griesbrei:

new software uses the new funktions and may use MP

mlelstv:

murty, the user would never know wether memory is protected or not. Every call will work with or without protection.

griesbrei:

old softare uses the old funtions and gets ONLY public

griesbrei:

so what`s the problem?????

Murty:

griesbrei: If the new software is the only one to use the MP, then it would go to the list 'additonal features' in my book.

stefanb:

BM: Not needed, if a pool is MP then all memory in the pool is.

Arcade:

We could actually have something like that in the system, having a program ask for it's memory to be protected. But it would not be very secure.

mlelstv:

bm, might be not enough.. but that's a detail..

Murty:

And new features are lower priority than getting an OS up and running, IMHO. They can be added later.

stefanb:

BM: If the hardware doesn't support MP, then the MP flag for pools will be ignored.

Pepo:

stefanb: if you do not want to bloat the OS, it makes sense to extend the existing libraries, and add new calls. you can do much code reusing internally this way.

griesbrei:

murty: what is an additional feature? MP?

mlelstv:

stef, you need new calls to handle ownership of pools.

stefanb:

Murty: Of course, because you have to design it for MP.

Murty:

griesbrei: Yes, if only used by new programs, then it would be a New Feature (tm).

mlelstv:

stef, I'd also make 'sets of pools' to avoid using half-full memory pages.

desrat:

murty:i agree....we have a greater need to get the new os up and running

BM:

Hmm, I think some allocations would have to be public, hence flags.

mlelstv:

stef, yes. I have a clear view of what such pools should do :)

Murty:

Okay, so suppose we do MP by pools, then we have to put that in the Exec design. Is Chris Gordon here, by any chance ?

griesbrei:

murty: we CANNOT add MP for old software.

stefanb:

But IMHO the biggest problem is that the OS wasn't designed to use MP memory...

Murty:

griesbrei: No, that's what I said.

Arcade:

Anybody with a real good reason for not making a new OS, and provide compatibility libraries *speak now*.

Arcade:

(we should get on to the next subject, on which we already were)

stefanb:

But I see no problems e.g. for Intuition to use MP, because onbly the program and intuition are _normally_ allowed to access the user interface strucutres for the program.

Murty:

Arcade: I just said we should be weary of the compatibility libraries, because we don't want to write an Amiga *emulator* !

griesbrei:

Murty: we NEED an emulator or no one will use our OS (no software)

Murty:

griesbrei: No, we need an OS that runs the applications in native mode. That will run old applications, but it won't have to translate all the old calls to new ones, like an emulator would have to.

Pepo:

stefanb: think what OpenWindow() does... it needs to change the NextWindow field of another tasks window...

griesbrei:

so, we`ll write a completly new OS and leave the old libraries. That`s it?

mlelstv:

arcade, a new OS is very difficult to test.. a rewrite and enhancement of the OS will allow partial testing

stefanb:

Pepo: But Intuition is SYSTEM SW, it is allowed to change SYSTEM structures.

Murty:

griesbrei: We'll extend the functionality of the old libraries, retaining their original structure and API.

Arcade:

mlelstv: How would you do that, SetFunction() every function in a library?

Pepo:

stefanb: but how would you protect another task doing it?

stefanb:

gries: And only NEW programs will be able to use the NEW calls.

griesbrei:

murty: and what if there comes an AmigaOS 4.0?

Pepo:

stefanb: run intuition in supervisor mode? change MMU tables? ugh...

stefanb:

Pepo: Decalre it an illegal operation. we are talking about running SYSTEM conformant programs.

mlelstv:

pepo, a window structure belongs to intuition. it might grant individual tasks read access.

Murty:

griesbrei: I've sent mail to CBM UK and I heard David Pleasance was going to contact me, but I've not heard anything yet.

Pepo:

stefanb: the point is you want it to be _secure by adding pritection_ instead of _secure by reliying on clean software_

mlelstv:

pepo, problem is that intuition would need a pool for each client :-/

Murty:

If there will be an AmigaOS 4, we would have to cooperate with its authors. No use in having two rival OSes.

rozga:

Isnt the point wether we want binary compatibility first or new features first?

stefanb:

ml: The pool would belong to the client. Because he is already using MP pools.

Arcade:

rozga: exactly, that's mainly the intention of vote #1.

Murty:

griesbrei: No, but if we have done a lot of work, they may want to benefit from it. And we may want something nice in return :-)

mlelstv:

stefanb, but intuition allocates it... from a clients pool ???

stefanb:

ml: Yep.

griesbrei:

Could you stop that thing on MP for a while please??

rozga:

Arcade: Did I miss the Vote #1?

desrat:

murty: a nice 4000 per contributer would be nice..:)

Arcade:

PieMan: whether we want binary compatibility or not.

BM:

I think features first but that the features will demand changes to binaries.

Tau:

mlel, why ugly? wouldn't the call be done on client's context?

Murty:

desrat: :-)) I was thinking more along the lines of being kept up to date on OS developments and a free registered developer membership for everyone, or something.

griesbrei:

Murty: Don`t want to work for C=, I want a complete PUBLIC os.

stefanb:

OK, vote #1: compatible OS, existing API. New features are only available through NEW API calls.

mlelstv:

tau, unsure.. intuition has to access its own structures too. it should not do this on the callers context

Pepo:

Tau: right, allocations of intuition objects should only be done on the context of the apps task

stefanb:

ml. Intuitions own structures are allocated on Intuitions task pool.

Murty:

Yes, Stefan. How will we do the vote ? Everybody be quiet for a while and two raises of hands in the shape of PINGs ?

mlelstv:

stef, I'd add new features to old calls too. like new tags or flags.

mlelstv:

stefanb, a call to intuition has to access multiple pools. how do you handle that if the pools are protected ?

stefanb:

ml: It only has to handle the tasks pool and Intution pools. No problem for that.

Pepo:

stefanb: though it is sometimes possible to add new features for old apps, e.g. customizable gadtools look etc...

-------- VOTE #1: Compatible OS, Existing API completely implemented -> Binary compatibility for old hardware. New features are only available through NEW API calls or new Tags (if possible).

Pepo:

again that should mean the api should be _expanded_ not replaced.

-------- RESULTS: 14 for, 4 against

griesbrei:

what`s that thing with `old hardware` (sorry)

stefanb:

griesbrei: Amiga (TM) hardware.

mlelstv:

griesbrei, new CPUs cannot be binary compatible..

griesbrei:

I think we should`nt change _anything_ in the old OS

griesbrei:

yes, but everybody keeps talking on changing the tags in the old OS

Tau:

gries, not change, ADD

Murty:

griesbrei: I agree with you as far as that we first have to make something with the current functionality, and only add new features later (NEW tags, etc.)

griesbrei:

mlel: no, add new libraries or add new funtions to existing stuff?

stefanb:

gries: Add new calls (and libraries if needed)

mlelstv:

griesbrei, compatibility is maintained by maintaining the old libraries.. simple and easy.

desrat:

pepo...the os as its stands is better than what they have

griesbrei:

some want to add new functions to the old libs, that`s not a good idea i think:

BM:

Hopefully, expanding them, wb.library would be fave.

Tau:

okay, in the first vote the decision was to retain and extend the existing API by adding new calls and tags to the old libraries whenever possible, instead of replacing whole libraries

stefanb:

BM: Kill WB :-) This would be a complete replacement, because it has NO features :-)

mlelstv:

griesbrei, depends.. a library should cover a specific topic. if you say want to add new gadgets to gadtools or new features to gadtools gadgets.. why not calling it gadtools.library ? why a new one ?

Pepo:

Workbench needs a MAJOR overhawl, but this should be clear to anyone...

mlelstv:

pepo, workbench is one of the trivial projects!

mlelstv:

pepo, it's really just an application

griesbrei:

melstv: again the problem with a new C=-made AmigaOS

Pepo:

mlelstv: still the nost important app :)

griesbrei:

melstv: if we change the existing libs, we won`t be compatible with new C= libs

mlelstv:

griesbrei, there won't be new C= libs for long and if this project gets really something done there has to be some cooperation.

Murty:

Since we are going to make an OS with all the old features built-in (along with some tags added for new functionality) and use all the new calls for new apps only, I think it's safer to make new libs for them.

jcompton:

If you want to be picky, there won't be any more C= libraries.

griesbrei:

mlel, pepo: ok C= might not come back, but what if it really comes back??

griesbrei:

That would be a real mess with our OS

jcompton:

gries: Commodore will be liquidated, hopefully within a month.

Murty:

jcompton: One of the reasons we started this project in the first place was that there may be no C= to give us new stuff, indeed. But I don't think we should exclude the possibility.

lemming:

Why not just add something to the begining/end of the replacement libraries

stefanb:

gries: A chance for our project and the Amiga, becuase WE already developed something that THEY can use. Remember 18 months before a NEW HW can come out.

Pepo:

griesbrei: if we implement most things C= would have done for 4.0, then there would be no problem for "them" (whoever) to join the work with us.

Arcade:

Murty: I agree with you, leave the old ones as they are ... add new features in additional ones.

mlelstv:

murty, the decision wether old or new lib should have nothing to do with new or old calls. libraries should cover some topic. i.e. you should not make a new OO system for intuition but adjust BOOPSI

Murty:

If we add calls at the end of a library and so does C=, that's a sure-fire way to break programs.

mlelstv:

griesbrei, they have to if they want to make new Amigas :)

stefanb:

gries: If developers use OUR OS, then they have no real choice :-)

Murty:

stefanb: Yes, but so far the most likely to succeed Amiga people (not Escom, but C= UK) have been 100% uncooperative :-(

Lynet:

Murty: Have you received a "NO" from C= UK, or haven't they answered your letter?

Tau:

future Amiga hardware producers have no reason whatsoever NOT to coopearte with us

PieMan:

we've been going for 1:20 mins now.. do you want to have the second vote??

stefanb:

Yes, let's go on to the next topic...

Tau:

what IS the next topic?

stefanb:

Tau: Resource tracking?

Pepo:

resource tracking can be done easily for _new_ apps. it is impossible for old apps.

mlelstv:

proposes a poor-man's resource tracking

Murty:

stefanb: I think it's more important to get some real stuff done, like a design layout, let alone some code.

Pepo:

there just needs to be an object pointer in the process structure that automatically gets disposed when RemTask :)

Pepo:

Kudo: because old apps don't know about resource tracking.

Kudo:

pepo: hmm.. true... isn't there some free space? don't remeber

mlelstv:

pepo, RemTask() is dangerous..

Arcade:

Yeah, but how to do that? Make a call something like TrackMe() to specify the object to be tracked?

Pepo:

mlelstv: ok, the internal DeleteProcess() from dos

Murty:

Resource tracking can be implemented quite easily, I think, albeit only for new applications. They should specify what resources can be freed and which are shared.

mlelstv:

pepo, means that you cannot kill a process easily.

Pepo:

mlelstv: kill = send a SIGF_ABORT signal

Arcade:

We would also need to add features to support the killing of tasks more easily.

mlelstv:

pepo, a program would have to wait for that signal.

griesbrei:

We should create an AddRTObject(object,type,hook) call

Pepo:

mlelstv: right. resource tracking only for new apps

Murty:

mlelstv: When the user would want to remove a program (that has crashed, for example, or is no longer wanted) the RT system will be able to determine what can an what cannot be freed/closed.

Arcade:

Why a hook?

Kudo:

pepo: why not just remove the task from the list, and free the resources?

Pepo:

every object _has_ a hook

mlelstv:

murty, even removing a task is dangerous, removing resources is even more dangerous.

griesbrei:

the type specifies how to remove the object if the system knows how to

Pepo:

Kudo: old apps _assume_ the resources won't get released, and usually leave them allocated _on purpose_

Arcade:

Unless you tell the OS it's safe to remove it if the tasks fails to.

griesbrei:

if the system doesn`t know about it, let the hook do the work

Murty:

mlelstv: Removing resources is not dangerous when the task expects it (i.e. when it set the MEMF_TRACK flag).

Lynet:

mlelstv: If new programs follow new rules, killing new programs and freeing the resources would work.

mlelstv:

murty, still dangerous when the new program calls old libs..

Pepo:

griesbrei: there should be only one "type" of object.

mlelstv:

lynet, agreed.. so someone has to propose the new rules.

Murty:

mlelstv: No, because the old libs will allocate resources with old flags. These resources will not be freed.

Pepo:

griesbrei: in other words, all objects can be disposed with the same call.

Murty:

(freed automatically by the RT system, that is)

Lynet:

mlelstv: I guess that would be a job for the design group.

mlelstv:

murty, means that each and every allocation needs to look for such a flag... hmm.

griesbrei:

pepo: yes, let`s call it RemRTObjects()

Pepo:

griesbrei: no, it's called DisposeObject()

BM:

If an application is trashed it may no longer be looking for signals.

griesbrei:

pepo: it just calls internal routines for known objects and the removal hook for unknown

Murty:

mlelstv: No, why would every application have to look for the flag ? That's all handled by Exec.

griesbrei:

pepo: again, i`m not talking of OO

desrat:

pepo:why do i always wind up with less mem when i remove an application..particularly graphics

mlelstv:

murty, Exec ? No.. lets say a task opens a window. it needs to tell intuition that the window should be closed when the task is removed from the system. intuition needs to free associated memory, and so on.

griesbrei:

pepo: just an internal list handled by the RT system

BM:

CreateNewProcess includes a field for a cleanup routine to be called.

Arcade:

But if the task crashed, it could mean the cleanup fails too ...

mlelstv:

bm, where is the advantage of such a routine called by the OS and such a routine called by the application ?

Murty:

mlelstv: Ah, I thought of that :) The window will be added to the resources list with the TRKTYPE_WIN flag, which is defined in . The freeing routine will call CloseWindow() on it. That's how it is in my head, anyway.

Pepo:

griesbrei: a list requires a node.

mlelstv:

murty, but each library, including user libraries can define their own objects..

griesbrei:

pepo: yes, the node will be created by the RT system

Murty:

mlelstv: Actually, that TRKTYPE flag is not hard-coded, it's allocated by Intuition. Oh, you just said that :)

stefanb:

Murty: Hmmm We shouldn't use static types. Every Object should be registered by a special resource.library.

Murty:

AllocTrackType() in exec.library...

Arcade:

How about the new program calling the DisposeOfThisObjectWhenImGone( void *window, TYPE_WINDOW ); ?

Tau:

mlel, rather, I think, for programs with the TRACK_MEM hunk flag, windows and other resources should be freed by default. If something wants to leave a resource behind, it has to declare it

stefanb:

That's clearly OO :-)

PieMan:

with RT won't that in some way affect the compatibilty?

Murty:

Tau: Makes sense, BUT then old programs would also have their resources tracked (all of them). And that will cause trouble, won't it ?

Arcade:

RT won't affect old (existing) programs if properly implemented

mlelstv:

tau, what about a simple callback function (dos.library/AtExit()) ?

desrat:

stepahnb:sorry..temporarily lost my resource allocation..:)

Pepo:

actually I'm not that convinced that RT is that neccessary. Apps need to free there resources anyway, when they exit cleanly.

Murty:

Arcade: Due to the sloppy use of the MEMF_PUBLIC flag, it WILL cause problems. Believe me.

Tau:

murty, see the bit about the TRACK_MEM hunk flag, which would only be set for new programs

Arcade:

pepo: But a task could always fail. If not by itself, then by another corrupt one.

Arcade:

Murty: We'll leave the MEMF_ flags alone.

Murty:

Tau: I'd rather have it as a call, say when you open a certain library than in a hunk.

Murty:

Arcade: Okay, and make a new AllocMem() for new programs. Fine with me.

stefanb:

Pepo: Resource tracking would ease some parts of programs, especially error processing...

Tau:

murty, there are piles of bits left for new AllocMem flags

Arcade:

Murty: Why the new allocmem? Just a call that says what type of object it is, how to free it (if necessary) and the OS will do the rest.

Pepo:

stefanb: _rely_ on the OS to do all cleanup?

Pepo:

stefanb: RT should not be (ab)used by apps.

Arcade:

Certainly not ...

griesbrei:

pepo: why not, at least you don`t have to

Murty:

Arcade: Ah, you're going OO here :-) That's more or less what I proposed with the TrackTypes back there.

stefanb:

Pepo: Then RT is not useful at all...

Pepo:

a program which opens a file, and doesn't bother to close it is BROKEN and belongs in the trashcan

Murty:

Tau: There may be piles of bits left, but we don't want to get in conflict with any possible new versions of the OS, from C= or whoever.

Arcade:

People ready to vote for resource tracking now? (only usable for new programs.)

mlelstv:

stefanb, still, any kind of resource tracking would help debugging (you know what belongs to what process). And you can make structured exceptions..

Kudo:

arcade: why only new programs!?!

Tau:

murty, we're writing the next OS.

Arcade:

Kudo: cause it would break older ones ...

stefanb:

ml: Yeah, but without C++ they are most of the time a pain in the a**

Murty:

Tau: Yes, but just in case. It'd be silly to have programs break over things like that.

Tau:

murty, C= engineers are not stupid. If we do something that gains users, they will support it. Especially if it's something they'd done anyway

Arcade:

I've just yesterday posted a nice example to the mailinglist.

griesbrei:

tau: C= engineers not, but the managers..

BM:

C= for lack of a better reference. :)

stefanb:

Tau: I would propose this: RegisterObject(), AllocObject(), DisposeObject(). When you allocate an object using this functions, you'll get RT for free.

Tau:

gries, managers don't decide what bits will be used for AllocMem flags

Murty:

Tau: But why would we be a pain in the backside to the C= engineers, who'd have to work around our system to make both systems compatible, when we can easily avoid it ?

Arcade:

stefanb: something along that way, indeed.

griesbrei:

tau: but they decide where to go

Tau:

stef, it's fine except it requires an extra call for each object

Lynet:

stefanb: Then you'd have to register *all* resources to get proper RT.

Tau:

gries, they don't decide details like this

stefanb:

Tau: After AllocObject() you can do TrackObject(), and it will be added to the "automatic" free list of your task...

stefanb:

Lynet: That's the price...

Pepo:

when we fear that there _might_ be a new (and different) OS from C= (or whoever), we could as well stop this project. Let's just ignore the possibility and continue (start?) working.

BM:

Ugh, open file, register file, close file.. Ick. :)

Arcade:

Okay, let's get on with the votes if that's okay with everybody ...

Murty:

Lynet: All resources would have to be registered, yes, but since most resources are allocated by library calls (CreateMsgPort(), Open#?()) they can do the tracking stuff

Tau:

pepo, yeah.. if there'll be a new OS from C=, why are we doing this in the first place?

mlelstv:

bm, not really. the dos.library would register the file for the process

Lynet:

stefanb: Ugh.. I wonder how many programmers are going to support this kind of cooperative RT.

stefanb:

BM: You allocate a FILE object, then you OPERATE on it, and after that you DISPOSE it.

stefanb:

BM: You can reuse an object...

stefanb:

Lynet: That's the price of a non-VM-system..

Murty:

Tau: There may never be. But we mustn't assume there WILL never be. It's short-sightedness like this that caused a certain business executive to say '640 kB ought to be enough for everyobody'.

Lynet:

Murty: You're right. Make OpenLibrary() do RegisterObject(), and so on.

Arcade:

The problem with old programs is that a resource might be passed over to another program, so the resource tracking would free the object and leave the other program in the cold with unallocated memory. That's why resource tracking is impossible for old programs.

Tau:

murty, if we're next, their will support our version

Pepo:

Lynet: there would only need to be a single bit in a hunk that identifies a "new" program

griesbrei:

just some words

Tau:

I think we should find a solution where the OS automatically enables RT for applications marked as stuff that want it

stefanb:

VOTE #2: Resource tracking should be implemented for new programs.

stefanb:

- Proposed API:

Pepo:

stefanb: also, only high level resources should be "trackable". It doesn't make sense to track a viewport, a colormap etc, when intuition tracks a screen itself...

stefanb:

- RegisterObject(): register a new object type for resource tracking

stefanb:

- AllocObject(): allocate an object

griesbrei:

leave that AllocObject away

stefanb:

- TrackObject(): Add an object to the automatic de-allocation list of the task

stefanb:

- DisposeObject()

Pepo:

stefanb: NewObject()

stefanb:

Pepo: There is already a NewObject()

stefanb:

Pepo: If you open a screen, Intuition handles the RT for you....

griesbrei:

RegisterObject and TrackObject are the same, aren`t they=

stefanb:

Pepo: The proposed API is for the OS and for user-defined objects.

Murty:

Who needs NewObject() if you have AllocObject() ? You need a MakeObjClass() though.

stefanb:

gries: Nope, RegisterObject tells the OS, there is a new Object and how to allocate/free it.

Pepo:

Mutry: ask the other way around: who nees allocobject() when we have newobject() (and we _do_ have NewObject() since v36)

griesbrei:

Can be done in one call, I think

mlelstv:

stefanb, NewObject() has nothing to do with Intuition. It is just in intuition.library

Pepo:

strfanb: it would be a MakeClass() call actually

griesbrei:

TrackObject(objectHing,type,hook)

stefanb:

Pepo & ml: RT has to be on the lowest level. not in Intuition.

Arcade:

stefanb: we also need a call then to tell the OS not to track.

stefanb:

gries: NO.....

mlelstv:

stefanb, BOOPSI _is_ on the lowest level. It is just misplaced in intuition.library

stefanb:

Arcade: Don't call TrackObject()!

Pepo:

Murty: you can call it how you want, but BOOPSI object system is completely generic.

stefanb:

ml: So we move the calls to Exec and the new Intuition uses the new calls!

Arcade:

stefanb: for programs that need to donate some resource to another program and has that HUNK bit set.

Murty:

stefanb: What if the library call calls TrackObject() ? You need a tag that says TAG_DONOTTRACK, for a shared resource for instance.

mlelstv:

stefanb, I suggest a new library that covers the objects and support calls from amiga.lib

Tau:

well, that's a minor detail. Shall we vote?

stefanb:

Arcade: If you don't call TrackObject() it's NOT tracked.....

stefanb:

ml: Exec seems fine to me...

Pepo:

ATOM - Amiga's Tagged Object Model, an enhancement of BOOPSI :)

Tau:

stef, but the hunk bit makes everything tracked by default, thus a DontTrack()

stefanb:

Tau: No, you have to state when you want to have a Object tracked. The flag only states that you want your resource automatically FREED!

Tau:

stef, good point

Pepo:

I don't see the difference (read: advantage) over MakeClass(), NewObject(), and DisposeObject() as we have them now.

-------- VOTE #2: Resource tracking should be implemented for new programs. Proposed API:

stefanb:

- RegisterObject(): register a new object type for resource tracking, tell the OS how to allocate and free it.

stefanb:

- AllocObject(): allocate an object

stefanb:

- TrackObject(): Add an object to the automatic de-allocation list of the task. Automatic de-allocation will only be used by programs which have a special HUNK bit set.

stefanb:

- DisposeObject(): Free an object.

stefanb:

- If a new program has a special HUNK bit set, it will use automatic de-allocation.

-------- RESULTS: 19 for, with 5 against the proposed API

Tau:

API details will have to be worked out at implementation point in a smaller group

Murty:

Tau: ...called the design team :-)

Lynet:

Whow. We agree on *one* thing. Perhaps there's hope for this project anyway. :-D

Arcade:

topic: multiuser security

Tau:

arcade, filesystem level or memory? we already have the first, the second is not a personal computer OS issue really

mlelstv:

thinks the proposed API is a misnomer.. there are no objects involved.

Arcade:

Mostly at the filesystem level. If we could add some more, that would be a bonus.

Pepo:

security? that sucks, slows things down, and isn't used by anyone.

Murty:

Tau: Filelevel system, please ! Memory level is one hell of a job and it requires a drastically different API from the current one.

Tau:

arcade, we HAVE filesystem level multiuser, so that's a non-issue

Tau:

murty, right, for one, it needs 100% MP

Murty:

As for MP, I didn't think the pools idea was bad. Again, new programs could automatically use protected memory and specify when they wish something to be shared.

Pepo:

Open() would just fail like with read protected files.

Arcade:

Is there? It needs to be supported within the OS, not by some external util.

Murty:

Like MultiUser is.

Pepo:

Arcade: the point is: there needs to be no redesign to support it.

mlelstv:

murty, the OS interface is problematic.. lots of unprotected stuff. But, in any case, the probability for trashing memory is reduced a lot. And that's why even partial MP is good.

Tau:

pepo, as it does already, if the filesystem looks at the protection bits

Arcade:

But the system does require additions ...

mlelstv:

tau, that's a filesystem issue. of course one should support ownership in the filesystem.

Pepo:

things that don't need a new API should of course go in, if they make sense

BM:

Is there anything that could be done to make multi user file system MUFS less of a hack and more secure?

Murty:

mlelstv: Yes, many things just can't be protected in the current system, like library bases etc.

Tau:

mlel, that's what I said ;)

mlelstv:

murty, library bases can be write-protected most of the time

Arcade:

Yes, there are certain things that could make it more secure.

Pepo:

like e.g. a Network filesystem (envoy)

mlelstv:

tau, just wanted to support you :)

mlelstv:

murty, to get reasonable speed one would need 'aliases'. You do not want to change the MMU all the time.

Murty:

mlelstv: No, the changing of MMU pages was one of the things that concerned me in MP.

Arcade:

So, do we include multiuser security then?

Tau:

I think we should have a vote about the protected memory pools. it has been discussed at some lenght already, so this should be quick

Murty:

mlelstv: It's too slow if you have to change them for every task, so the tasks would even have to share the same protected pool (?)

Arcade:

Let's have a proper vote anyway about a muFS-alike system.

Tau:

arcade, of course. Not including it would be dropping features, which I thought we decided not to do with the vote #1 ;)

mlelstv:

arcade, we cannot include security for local processes. the machine has to be a single-user machine. but it can provide multiuser services over a network.

mlelstv:

murty, no. each task has its own MMU table.

Tau:

everyone is for a filesystem with multiuser support, so there's no need for a vote

mlelstv:

murty, overhead for that is not that high..

mlelstv:

murty, basically you have to reload the ATCs at every task switch.

Arcade:

okay, voted unanimous then for multiuser-filesystem.

mlelstv:

murty, MP pools could even work for many old programs !

Murty:

mlelstv: How intensive is that ? How much relative time does it take, compared to just a task switch ?

Tau:

mlel, which is a nice extra ;)

mlelstv:

murty, you loose a few microseconds per taskswitch..

Pepo:

an MMU table switch is a write to a processor register.

Arcade:

Can someone in short enlighten me on this subject? (MP using pools)

mlelstv:

murty, the scheduler just sets the root pointer. the MMU will then have cache misses.

stefanb:

Vote #3: Add a memory protection flag for Pools (which will be ignored on machines without MP).

Murty:

Pepo: what about continually updating and changing the MMU tables ?

Kudo:

knows nothing about MMU's and MP pools... =(

Pepo:

the overhead comes with maintaing shared trees when there would be virtual address spaces.

Pieman:

not many people have mmu's anyway

griesbrei:

stefan: add a PUBLIC_READ and a PUBLIC_WRITE flags

Tau:

murty, it will add some overhead to AllocMem/FreeMem, but since it's using pools, they are not called that often

stefanb:

Piemann: They will have :-)

mlelstv:

arcade, you do not want to protect individual allocations (overhead). so you protect pools. pools (one or more) can live in a memory region made of MMU pages. Each set of associate pools has specific protections.

Kudo:

pieman: not many ppl have more than 640k...

stefanb:

Maybe each new program should get a MP pool automatically?

Lynet:

On the topic of MP - is it possible to protect the OS, or parts of the OS?

Arcade:

And what exactly is a pool? Is it private to a program, or can any process allocate from it?

mlelstv:

stefanb, that was my proposal.. each process has its own private pool and AllocMem/AllocVec automatically use that pool!

griesbrei:

a pool is private to the process

Tau:

stefanb, yes. Every program should get a private pool on NewTask(), whether they use it or not is their own problem

Pepo:

stefanb: for new apps non-public AllocMems() could use a system-provided private pool.

mlelstv:

griesbrei, not necessarily.. you can allocate pools to be shared.

Murty:

mlelstv: Doesn't the pool idea imply that there will always be a part of the memory that is protected and a part that is not ? You'd add another CHIP/FAST division. What if unprotected memory runs out while there is still some protected left ?

Tau:

an old program would not allocate any memory from the protected pool, but instead use the shared pool for everything

griesbrei:

Tau: ..and add something like `This one needs 1Megs of RAM` like in Windoze??

mlelstv:

murty, it's not a fixed division, it is just an attribute reflected by the MMU settings

Pepo:

Gee, My Amiga ran out of protected memory!!

stefanb:

Murty: No, the memory in one pool is always of the same type.

Tau:

gries, no. Pools get new memory allocated to them dynamically when they run out of free space. You just allocate memory in larger blocks

mlelstv:

murty, when a pool needs another page it simply gets the same attributes

Pepo:

protection is not a "type". Any (non-chip) memory can be protected.

Pieman:

yes but it is possible that a program will need an increasing amount of memory, ie in mosaic storing the pictures

stefanb:

Piemann: But the will automatically shrink too...

Tau:

pepo, you'd run out of shared memory first. Every task would have its own private, protected address space

Murty:

mlelstv: I understand that. But if you have a large pool of memory (say 1 MB) that is protected and another one (4 MB) that is unprotected. An old program will use shared memory, so fill up the 4 MB. What if they run out while there's still 1 MB not being used ?

Tau:

gries, when it does the first AllocPool(), the pool is grown to, say 64k. When that runs out, another 64k is allocated.

mlelstv:

murty, the pools are allocated by the programs.. there won't be (much) free space in any pool.

BM:

With memory protection, will it be possible to keep the API? Will addresses still be returned in messages to detemrine what gadget was clicked on for example?

Arcade:

Let's say the pool is at the end of allocated memory, how would it be able to expand?

Pepo:

Arcade: the MMU can remap

mlelstv:

arcade, just it expands now.

mlelstv:

arcade, a pool is made of puddles

Tau:

I posted a long article about this to the mailing list some time ago. Mlelstv commented on it, but I don't know how many of you saw it. I can send that if you want to see it

Pieman:

i guess it expands and shuffles the other pools along

Murty:

But if a pool grows dynamically, there will still be a lot of overhead when allocating, wouldn't there ? Wasn't that what we tried to avoid ?

mlelstv:

BM. that's the reason why MP cannot be 100%.

Tau:

stefanb, but the protected pool can be in private address space, and thus put in virtual memory

Pepo:

Pieman: no, thats what the MMU does. it translates addresses without copying the actual data.

mlelstv:

pieman, pools still are subject to fragmentation (within the pool). But most pools are per-process, when the process dies the fragmentation is gone.

Pieman:

pepo: so it's a bit like a fragmented harddisk..

mlelstv:

tau, any pool can be in virtual memory.

Pepo:

Pieman: no, seeking in memory doesn't take time :)

Tau:

murty, every time the pool is grown, the MMU table has to be adjusted. Which is why it is a pool, instead of forcing an adjustment on every memory allocation

Pepo:

rozga: VM already works, doesn't it?

Pieman:

where is this mmu table stored? does the mmu unit have it's own memory or do we have to allocate it a pool of it's own?

Murty:

rozga: Not yet, but it will probably also be like the RT solution, only for new programs that is. I emailed the author of VMM and he said VM with the current OS was a bit of a hack :-(

Tau:

this pool stuff would make it HEAPS easier for VMM to operate

stefanb:

Pieman: That's the task of the OS...

Tau:

murty, because it has to hack in functions that are not designed for it.

mlelstv:

pieman, it's probably not a pool as it has to reside in its own pages.

stefanb:

Piemann: But probably write protected by the OS...

Murty:

Tau: So, the pool will grow a lot. If you make a puddle of, say, 64 K, then for every 64 K of memory allocated, a MMU table would have to be rebuilt. Sounds like a lot of overhead to me !

Lynet:

Tau: With pools, VM would be implemented by swapping out/in an entire pool?

griesbrei:

lynet: the puddles of the pool

Pepo:

Lynet: no, a page.

stefanb:

Murty: Less overhead than with MMU adjustement every AllocMem()

mlelstv:

pieman, there is a lower level that handles regions of memory with certain attributes. The MMU table will use its own region

BM:

I think all these shareware authors should be contacted for their opinions on what hacks they had to perform to get their code to work.

Pepo:

Lynet: a page of a pool. every page could hold many puddles (allocations) though

Murty:

Tau: No, mainly because the MEMF_#? flags are abused by many applications and it's very hard for VMM to determine what it can cache and what it can't. System structures, for example, cannot be cached, so VMM looks if the allocation is smaller than, say, 500 bytes before writing disk

Tau:

lynet, no, a page at a time. but the VM table need to be updated only when a pool grows/shrinks

mlelstv:

pepo, means that you want multiple pools per page.

Tau:

murty, that and lack of pools

stefanb:

Murty: MP is only for new programs. VMem too...

mlelstv:

tau, not even then.. just when the pool needs more/less pages

Murty:

stefanb: I know that. I was just explaining that :)

Tau:

murty, protected pools would make VMM magnitudes simpler

Pepo:

mlelstv: if they have the same attributes, who not?

mlelstv:

stefanb, MP+VMEM can work, often, for old programs too

Tau:

mlel, I'm assuming puddle size > page size

mlelstv:

pepo, I did propose that :)

Murty:

Here's my suggestion : use the pools for VM, but let's forget about MP. It's probably going to be kludgy anyway, with so much stuff unprotected.

stefanb:

OK, what should we vote on? Just "We want to implement MP (and VMem) for memory pools"?

mlelstv:

tau, well, yes.. but with 8K pages this might not be the case :)

Arcade:

tau: better puddle size = X * MMU page size

stefanb:

BM: Machine dependend. The puddle size will be adjusted by the OS.

mlelstv:

arcade, or 1/X * MMU page size

mlelstv:

stefanb, the puddle size is suggested by the application. it might be adjusted though.

Tau:

mlel, no point making it smaller than MMU page.. you reserve the whole page anyway

Pepo:

mlelstv: a puddle is what you get returned from AllocPooled()

stefanb:

ml: That's what I meant... The same is alread true for AllocMem().

Murty:

Here's my suggestion : use the pools for VM, but let's forget about MP. It's probably going to be kludgy anyway, with so much stuff left unprotected.

mlelstv:

tau, a program should chose puddle sizes for specific objects (to minimize fragmentation). a task may have many pools and not all of them will require their own page

Tau:

murty, MP is a VERY VERY nice thing to have. and a VM API is so close to MP API there's no point in not having both

Tau:

mlel, I'm talking of the task global MP pool, tho

caldi:

Murty: Perhaps someone should contact Mike Sinz, according the the devcon notes, C='s VM plans were pretty far along. They too planned VM in pools with the PAGED attribute.

mlelstv:

tau, well.. that's not necessarily what we called a 'pool' :)

Murty:

stefanb: Well, kludge is not the right word. The Dutch word I'm looking for is 'halfbakken', which is something like half-decent. You can only protect half your resources, but if the unprotected half is corrupted, chances are that the rest will go down with it.

Tau:

murty, half-baked is an English phrase, too ;)

Arcade:

murty: exactly. MP can never be safe ....

stefanb:

Murty: But better this than nothing...

Tau:

arcade, MP is inherently safer then no MP

mlelstv:

tau,arcade: safe but not secure

Murty:

Tau: But is half-baked :-) protection worth the effort ?

stefanb:

Arcade: The program will still work though, because the OS ignores the MP flag on non-MP hardware.

Tau:

murty better than none at all

stefanb:

Murty: You aren't a programmer, aren't you? :-)

Tau:

stefan, we should also make it optionally ignore it on user request (an old program kludge)

Murty:

stefanb: I am, actually. Why ?

-------- Vote #3: Add memory protection to memory Pools.

stefanb:

- MP will be ignored on non-MP hardware

stefanb:

- MP can be switched off if the user wants.

stefanb:

- New programs automatically get an MP memory pool for their purposes.

-------- RESULTS 15 for, 1 against

-------- Vote #4: Same points for Virtual Memory.

-------- RESULTS 15 for

mlelstv:

griesbrei, the most probable thing is that while parts are rewritten they get new features on the way.

Lynet:

Pepo: Which new features has been added to intuition-clone?

Murty:

One topic I'd just like to mention is the speed at which is project is, or rather isn't, moving. Does anyone have a brilliant idea to speed things up on the designers list ?

caldi:

Murty: Is there a designers list one can read over, perhaps commit to some part of the project?

Pepo:

Lynet: not much yet: window hiding, realtime resize and drag, several bugfixes, a new gadget method, new mulitple pen array support for borders and some other small things (mouse acc etc)

Lynet:

Pepo: Sounds nice. Is it soon ready to distribute to betatesters?

Pepo:

Lynet: I expect to have a working _alpha_ version in 2 months. several old (v40) things are not done yet (e.g. no sysreqs, no custom pointers, no sysiclass, ...)

Lynet:

Pepo: Ok. Can't wait to start betatesting. :)

Pepo:

lynet: alpha, not beta. beta versions to be released in perhaps 8 months

Pepo:

Tau: alpha testers will be programmers only, not users.

Tau:

pepo, programmers of intuition?

Pepo:

Tau: yes.